comp-utils.scm - added many (but not enough) vital scheme functions to
scheme-reserved-names global (see below, known bugs)
compiler.scm - per JMiller 8/8/93, made changes in function thomas
to properly compile expressions
implementation-specific.scm - many hacks to cause Thomas to print Dylan objects in a more civilized fashion when in the debugger instead of pages of recursive vectors (again, see below, known bugs); specifically
make-condition - let MacGambit have the error arguments so the debugger prints something useful
implementation-specific:enter-debugger - fix a bug with outputting messages
rep.scm - many, many hacks to improve debugger and printing of Dylan objects. The old debugger just aborted to top level without telling you anything.
Known bugs -
Thomas is VEEERY slow. I made an array class and tried multiplying two 4x4 array instances, and it took over 2 minutes. I traced one of the underlying scheme functions (a structure accessor) and found it getting called 70 times for one slot accessor function call. Attention all hackers - how about memoizing these function calls?
You can only compile a .dyl file into a .dyl.scm file in a "clean" world - i.e., one that has not seen any of the expressions in the .dyl file. If a file is compiled a second time in that world, bad code is generated since things that it has seen it handles differently (in this case, wrongly) than totally new things. That means if you are doing code development you need to load from scratch EVERY time. You may zap expressions repeatedly from a file into Thomas all you want-that still works.
The use of Bind only allows about 12 variables before the MacGambit compiler gags on the .dyl.scm file having code segments above 32K (!). Only of interest if you want to build an application on top of Thomas and make a world
The same concern applies to the maximum number of slots on a class definition - you can inherit in all you want, but 10 seems to be about the maximum number for a new class.
Although many pains have been taken to improve the printed representation of Dylan objects, there are still situations where pages of garbage start flowing - specifically, if you show a list or vector of Dylan objects. The quickest way to halt that is by typing <Apple>-. (the interrupt key).
Beware of variable names in a Bind that are the same as method names - you will LOSE! and never have a clue why. This bug doesn't let you know anything - Thomas just goes off and never returns.
If you work at all in MacGambit Scheme (i.e., you type thomas:done and pretend you don't have Dylan), be aware that even the mention of an unprotected (not mentioned in scheme-reserved-names) function in Dylan will nuke the definition of that function until you reload the file. Many essential scheme functions are NOT protected: people are welcome to add to the list if they have lots of spare time. And of course any functions you define are unprotected. This also applies to global variables, too.
If you are in scheme, the hacks for civilized printing of Dylan objects no longer apply (sorry!). Also, if you are in Scheme and you generate an error, the debugger is Thomas, not Scheme, so the above warnings about clobbering your scheme environment apply especially.
And on the subject of debugging environments - the stuff on the debugger stack is not particularly helpful, since generic functions get turned into anonymous procedures, and because all the underlying Scheme code is ALWAYS compiled, the debugger can't show local variables.
Cool Feature - if you define a variable in Thomas, you can reference it in scheme by the same name:
(set! foo (make <fudge> flavor: "chocolate"))
(set! bar (+ 43 19))
thomas:done
bar 62
foo <pages and pages of garbage that is the print representation of instance foo>
